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Abstract. We present a deductive approach for the analysis of secure 
information flows with support for fine-grained policies that include de- 
classifications in the form of delimited information release. By explicitly 
tracking the dependencies of program locations as a computation his¬ 
tory, we maintain high precision, while avoiding the need for comparing 
independent program runs. By considering an explicit heap model, we 
argue that the proposed analysis can straightforwardly be applied on 
object-oriented programs. 


1 Introduction 

An information-flow analysis tracks where and how information flows within 
an application to control which inputs may or may not affect what outputs. 
The typical information-flow policy that no information may flow from sensitive 
locations to less sensitive ones |Coh77) is known as non-interference |GM82) . In 
practice this policy turns out to be too strong for many programs: even a simple 
password checker needs to reveal whether the entered password is equal to the 
actual password or not. It is therefore common to enforce a more liberal policy 
that allows for controlled release of information: a policy with declassifications. 

In our previous example, a declassification policy would specify that the 
outcome of the equality check with the actual password may be leaked, but 
no other information (in particular, the actual password must not be leaked). 
This kind of declassification can be refined with conditions stating under which 
circumstances certain information may be made public and is called delimited 
information release. In this paper we consider a (very) simplified program that 
decrypts a ciphertext but only returns the result if it has a valid padding and 
the integrity check, i.e. the checksum, succeeds. This program, shown in Fig. [1] 
complies with a policy with two declassifications: we unconditionally declassify 
whether both checks hold (but not whether the individual checks hold), and we 
declassify the decrypted message on the condition that both checks hold. 

Information-flow analysis can be rephrased as determining the dependencies 
that a program introduces between the input and output locations |Coh77) . That 
is, determining whether sensitive information flows to a less sensitive location 
can be rephrased as determining whether the final value of that less sensitive 
location depends on any sensitive input. 








msg = cipher * key; 
paddingQk = msg 7, 256 == 0; 
if (paddingOk) { 

checksum = (msg / 256) % 256; 
if (checksum != -1) { 
result = msg; 

} else { 

result = -1; 

} 

} else { 

result = -1; 

} 


Fig. 1. Simple ’decryption’ algorithm: 
Decrypted ciphertext is only revealed if 
padding and checksum of msg are valid. 


objA.f = 1; 
objB.f = 1; 
if (h == 0) { 
objC = objA; 
)■ else { 

objC = objB; 

> 

objC.f = 17; 


Fig. 2. Information-flow via aliasing: 
Information flows from h to obj A. f 
without an assignment using variable 

ObjA. 


We present a logic-based approach to information-flow analysis, which im¬ 
proves on earlier work |BHW09] by one of the co-authors, which focused on 
automating software verification by integrating abstract interpretation to gen¬ 
erate loop invariants. Non-interference checking was used as a show-case for 
their framework. Their logic allowed to identify the dependencies in commands 
as X := y; z := x (z depends on y, not on x) and x := y; x := 8 (x does 
not depend on anything) which are typically over-approximated by e.g. flow- 
insensitive type systems for information-flow [BvDS13IHS06IVS97] . 

However, their approach tracks dependencies on memory locations directly 
and performs over-approximations when syntactically inspecting the variables 
occurring in expressions. The logic presented in this paper increases precision by 
maintaining some information on how variable dependencies contributed to the 
value of an expression and allows us to formulate the desired fine-grained security 
conditions. In more detail our contributions are: (i) Tracking of dependencies 
using a term structure instead of sets of variables to provide higher accuracy 
of the information-flow analysis: Approaches like |BHW09] add for programs 
like x=y-y or if (y) {x=8} else {x=8} variable y as dependency of x, but our 
analysis does not. (ii) Support for precise conditional declassification policies: For 
the program in Fig. [T] we can specify that result may depend on cipher * key 
only if both padding and integrity check succeed, (iii) Extensible to an object- 
oriented setting (hints are given in the paper) to analyse complex information 
flows as shown in Fig. [51 The presented program logic can be integrated into the 
loop invariant generation algorithm presented in |BHW09] . 

Paper outline. We first introduce syntax and semantics of both programs and 
the program logic in Sect.Hl as well as a sequent calculus to prove the validity of 
properties specihed in the program logic. In Sect. |3]we extend the semantics of 
the program logic to encode security conditions (non-interference and delimited 
information release) as program logic formulas. Sect. U] presents an extension 
to the sequent calculus to prove the validity of these formulas. In Sect. [S] the 
program logic and calculus are applied to the programs in Figs. [T] and |2j The 
Sects. El and [7] conclude the paper by discussing related and future work. 
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2 Syntcix and semantics 


This section introduces an imperative programming language, a program logic 
to specify general functional properties and a calculus to verify that a program 
satisfies its specification (mostly taken from |BHW09] 1. The formal treatment 
of our extensions is based on these definitions. At the end of the section we 
extend our programming language by adding object-oriented features in a semi- 
formal manner, which serves us to demonstrate how to extend our approach to 
a programming language with a heap. 

We define now the syntax of our programming language and logic. The signa¬ 
ture of the logic is defined as A = {T, a, V, -F, W, CV} with T gT a, sort name; 
a assigns an arity to (i) each predicate symbol p G V as a(j)) = Ti x ... x Tn, 
(ii) each function symbol f G T as a{p) = Ti x ... x Tn ^ T (constants are 
modelled as functions with no arguments), (iii) each program variable x G W 
as a(x) G T and (iv) each logical variable y G CV as a(y) € T. 

Logical variables can be bound by quantifiers and are not allowed to occur 
in programs. Logical variables and all function symbols are rigid symbols, whose 
value cannot be changed by programs. In contrast, program variables cannot be 
bound by quantifiers, but are allowed to occur in programs. Program variables 
are non-rigid symbols, i.e., their value is state-dependent and can be changed 
by program execution. Further, there are predefined sorts T G T and int G T 
and predefined predicate symbols <,<,>,> and function symbols -b, —, x, /,% 
with their canonical arithmetic signature. 

Definition 1 (Syntarx). Program p, updates u, terms t and predicates (p are 
defined as all well-typed words generated by the following grammar: 

P X = t I if((p){p}else{p} | while((p){p} | p;p 
u ::= X := t \ u\\u 

t--=^\y\ f{t, ...,t) I t(• G {-b,-, x,/,%}) I if{ip)then{t)else{t) \ {«} t 
p ::= true | false | p(t,... ,t) \ t = t \ \{p \ p o p \ 3y.ip \ \/y.(p \ 
if (if) then (ip) else (if) \ {w} p \ [p](p 
where o G {&, |, —>}, y G CV, x G PV, f G P,p G V 

Terms and formulas that appear inside programs may not contain any logical 
variables, quantifiers, updates, or nested programs. 

Like programs, updates can be used to describe modifications of the non- 
rigid symbols (i.e. program variables). That is, [p]<p denotes that p should be 
evaluated in a context where the value of the program variables has changed 
according to p. Similarly, in {u} p the update u describes how the values of 
program variables change before evaluating p. Intuitively, updates can be seen 
as a kind of explicit generalized substitutions, which are simplified during and 
their application is delayed until the program has been symbolically executed. 

An elementary update it is a pair x := t where x is a program variable and 
t a term of the same sort as x. Elementary updates iti,ii 2 can be combined to 
parallel updates iti || U 2 . 
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Example 1. To explain the intuition behind updates we give a few examples. 

— {i;=a+l}i>a expresses that the program variable i is greater than a 
when evaluated in a state where i has been set to a + 1. 

— oldi = oldj —^ {i := j || j := i} (i = oldj A j = oldi) expresses that 
the values of i and j are swapped. Note: Parallel updates are ‘executed’ 
simultaneously without effecting each other. 

— {x := 4 II X := 8} X = 8 evaluates to true; i.e. in case of competing updates, 
the right-most update wins. 

To give semantics to dynamic logic formulas, we require a first-order structure 
to give meaning to sorts, functions and predicates, a state to give meaning to 
program variables and a variable assignment to give meaning to logical variables. 

A first-order structure M is a pair (D, I) where D is a domain, i.e. a non-empty 
set of elements. The interpretation function I assigns 

— each sort T € T a non-empty set l(T) C D of elements. 

— each function symbol f:TiX...xT„^T eJ^a total function Iff) : 
l(Ti) X ... X l(r„) ^ l(T); and 

— each predicate symbol p : Ti x ... x T„ gV a relation l(p) C l(Ti) x ... x l(T„) 

In particular, I is fixed for sorts T and int such that /(T) = D and /(int) = Z. 
In addition I is also fixed w.r.t equality l(=)(wi, ^ 2 ) = tt iff. ul = v2 and functions 
like -b, —, X, /, % which are interpreted as the standard arithmetic operations. 

Given an interpretation function I, a state s assigns each program variable 
X G W of sort T a value s(x) G l(T); the set of all states is denoted S. A variable 
assignment (3 assigns each logical variable y G CV of sort T a value /3(y) G l(T). 

Definition 2 (Semantics). 0 Given a first-order structure M, a state s and a 
variable assignment /3, the semantics is defined by function valM,s ,0 evaluating 

— terms to a value valM,s,p(t) G D, 

— formulas to a truth value valM,s,i 3 {‘p) G {tt,ff}, 

— updates to a result state valM,s,i 3 iu) G S, and 

— programs to a set of states valM,s,p{p) & 2“^ with cardinality either 0 or 1. 

A formula ip is called valid iff. valM,s,p{'p) = tt for all first-order structures M, 
states s and variable assignments ft. 

A diverging program evaluates to the empty set. As our programming lan¬ 
guage is deterministic, a terminating program has exactly one result state. 

Example 2. Example evaluations with s = {x 1 —>• 4} and /3 = {j/ 1 —>• 3}. 

~ valM.s.piy + 3) = 6 

— valM.s,p{[y^ = 1; X = 2]x = l)=if 

— valM,s,p{^ := X -b 1) = {x 5} 

— valM.s,^^^ = 1; while (x>0) {x = x+l; }) = 0 
^ valM,s,p is defined formally in Appendix lA.II 
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— valM,s,p{^ = 1; while (x>0) {x = x- 1; }) = {{x i—0}} 

As mentioned earlier, we add now some object-oriented features to our pro¬ 
gramming language. This allows us later to demonstrate how to extend our ap¬ 
proach to programming language with heaps (and hence, aliasing). The syntax 
of our programming language is extended by the following three statements: 

p ::= ... I x.f = t \ X = t.f I X = new 

which allow to assign a value to the field / of an object x, to read the value of 
an object field and to create an object. Fields are simple names, where different 
names identify different fields. For the modelling on the logic level we require 
the existence of four additional sorts: Object (the sort of all objects), Field 
(whose domain elements represent fields), a Heap datatype to model the heap 
and the sort HeapValue being the smallest supersort of all sorts except Heap. 
The heap is modelled using the theory of arrays, i.e., there are two additional 
function symbols store : Heap X Object x Field x HeapValue —>■ Heap and 
select : Heap X Objectx Field —t HeapValue. Further there is a global program 
variable heap € T^V, which refers to the current heap and is updated or queried 
each time a program writes to or reads from the heap. 

Example 3. Given two program variables o,u S VV of sort Object and two 
unique constants a, b of sort Field (unique constants refer to different domain 
elements iff. their name is different), then the term 

— store(heap, o, a, 5) represents the updated heap after assigning o.a the 
value 5. 

— select(store(heap, o, a, 5),u,b) retrieves the value of u.b from the heap 
given as first argument. Since a and b refer to different fields the term is 
equivalent to select(heap,u,b). 

2.1 Sequent calculus 

To reason about the validity of formulas in our logic, we use a Gentzen-style 
sequent calculus |Gen35] . In particular, we build upon the calculus used for 
JavaGardDL [BHS07] . The basic data structure for our calculus is a sequent 
r =^> A where T, A are sets of formulas. A sequent is valid iff. the formula 
/\(/>Gr y valid. A sequent calculus rule is an instance of the rule 

schemata: 


premises 



conclusion 


Rules with an empty premise are called axioms. A sequent proof is a tree where 
each node is labeled with a sequent and the root node is labeled with the sequent 
to be proven. Each node (except the root) is the result of a rule application. Let 
node n be the i-th child of node p, then there is a rule r such that the conclusion 
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of r matches the sequent of the parent of n and the sequent of n is equal to the 
instantiated i-th premise of r. A branch is closed if on one of its nodes (usually 
the last one) an axiom has been applied. A proof is closed if all its branches are 
closed. The calculus is sound, if it only allows to construct closed proofs when 
the root sequent is valid. 

The calculus rules for first-order logic are standard and not given here, but 
we explain the basic idea for the rules dealing with programs (see |BHS07| for 
more details). Our calculus follows the symbolic execution paradigm and models 
a symbolic interpreter for the programming language. The sequent rule for a 
conditional statement looks like 

r,(p=^[p-,...](j>,A r,\(p=>[q-,...]4>,A 

conditional - 

r [if (v5){p; }else{q; }; . . A 

which splits the proof into two parts, one where the condition is assumed to 
hold and consequently, the then-branch of the conditional statement is executed 
followed by the remaining program and the second one dealing with the case 
that the condition evaluates to false. 

We give now the assignment rules for local variables and heaps 

assignjocai assignjieid 

r => {m} {v := t} [. . A r => {m} {heap store (heap, o, a, t} [. . .]</), A 

r => {u} [v = t;. . A r => {m} [o.a = t; . . A 

The rule assign jocai turns an assignment to a local variable directly into an up¬ 
date, while rule assigPfieid updates the heap. During symbolic execution updates 
accumulate in front of the program modality until symbolic execution finishes 
and are then applied to the postcondition similar to a substitution. This delayed 
application allows us to perform simplifications on updates before their applica¬ 
tion and avoids case splits as well as introduction of fresh variables after each 
assignment. The calculus rules for update simplification and application can be 
found in |BHS07) . 

3 Security conditions 

In this section we define information-flow policies as formulas in our logic. First a 
definition based on program variable dependencies for non-interference following 
the work in |BHW09] is given, which is then extended to express the more fine¬ 
grained conditions of delimited information release. 

3.1 Non-interference as a program logic formula 

With the semantics in place, we can give a more formal definition of non¬ 
interference. An observer with security level I can observe all information of 
levels I' ‘below’ I, that is information labelled with level I' Q 1. Given a policy 
7^ = (L, C) (a set of levels L with a partial relation C between them) we assume 
a mapping Ivl from program variables to their intended security level. This leads 
to the following definition of equivalent states for an observer on level 1: 
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Definition 3 (Z-equivalent states). Given V — {L, C), let I be a security level 
in L. Two states si,S2 are l-equivalent, written si S2, iff- for all program 
variables x with lvl(x) C I, it holds that si(x) = S 2 (x). 

A program p is defined non-interfering if it preserves /-equivalence for all levels 1: 

Definition 4 (Non-interference). Let V = (A,E). Given a program p, any 
two states Si,S2, any first-order structures M and any variable assignments j 3 , 
such that valM,si,p{v) — {si} and valM,s 2 ,p{v) = {s^}- Then p is said to be 
non-interfering with respect to V iff for all I S L, when si S 2 then s( s^. 

Definition |4] is termination insensitive, because we assume termination of 
program p. As a consequence, an observer may learn more information via the 
(non-)termination of p than specified by the policy P |AHSS08) . 

It is well-known that the non-interference of a program can be phrased in 
terms of the dependencies that the program introduces between the initial and 
final values of program variables |Coh77IHS06) . That is, if the final value of x 
depends on the initial value of y, we know that there is interference from lvl{y) 
to lvl{x) and we should therefore check that lvl{y) C lvl{x). 

We present as a small generalisation the dependencies of terms, rather than 
just program variables since we allow for the declassification on the granularity 
of terms and not just whole variables in the next section. Clearly, by choosing 
the term to be a single program variable the following definition is equivalent to 
dependencies for variables. 

Definition 5 (Term dependencies). Given a program p and a term t. The 
term dependencies of a term t under p is defined as the smallest set V{t, p) C 
of program variables such that for all states si, S2, any first-order structures M 
and any variable assignments ff with valM,si,p{v) = {si} and valM,s2,/3{'P) = 
{S2}; we have if for ally G T’(t,p) si(y) = S 2 (y), then valM,s[,ii{t) = valM,s’.^,ii{t). 

We can now define non-interference in terms of dependencies as argued: 

Definition 6 (Dependency-Based Non-Interference). Given a policy V— 
(L, C). A program p is non-interfering with respect to V iff for each variable 
X G PV, for all variables y G X>(x,p), it holds that Ivlfy) C lvl(x). 

Lemma 1. Definitions^ and\^ are equivalent. Proof in Avvendix \B.l[ 

The security condition can be expressed (per program variable) as a program 
logic formula (see |BHW09) 1. For this purpose, a ghost variable x'^®? is introduced 
for each program variable x. Assume that x, y and z are the only variables in 
program p, lvl{y) Q lvl{x) and lvl(z) lvl(x). When we extend the function val 
appropriately to update the state such that x‘^®p contains (an over-approximation 
of) the set of dependencies of x, we can express the security condition as: 

x"®P = {x}&y"®P = {y}&z"®P = {z} ^ [p]x"®P C {x,y} 

For a more formal description of how val is extended to over-approximate 
the dependencies, we refer to [BHWOQj . 
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3.2 Non-interference with declassifications 

In this paper we allow for the specification and verification of more fine-grained 
security conditions than non-interference on program variable dependencies. As 
illustrated by the decryption example in Fig. [TJ we desire more control on when 
information may interfere, and on what information from the initial state is 
released, as per the dimensions of declassification |SS05j . 

As a means of specifying such conditions, we introduce a declassification 
environment DE to the security policy V = (F, Ej DE). A declassification envi¬ 
ronment maps security levels in L to a set of declassification pairs consisting of 
a formula (when) and a term (what). That is, (^p,t) € DE(l) specifies that when 
ip holds on the initial state, the information about that initial state as specified 
by term t may be declassified to level 1 . 

For example, (password = guess, (salary 1 -f salary2)/2) G DE(lo'w) spec¬ 
ifies that the average of two salaries may be released to security level low if the 
right password was entered (regardless of the security level of each salary). 

We can define the equivalence of states with respect to a set of declassification 
pairs DP, as agreeing on the information that is declassified whenever both states 
allow for the declassification. A similar notion is used in |BNR08lVDGD~*~l^ for 
‘flowspecs’ resp. ‘stateful declassifications’. 

Definition 7 (HP-equivalent states). Given a set DP of declassification pairs, 
a first-order structure M and a variable assignment fi. Two states si,S 2 are 
DP-equivalent, written Si ^dp S2, iff for all (ip,t) G DP, if voIm, si, p(t) = 
val^,s 2 ,p(T) — tt then val]'i^ s,^ is(t) — ralj[r,s 2 ,p(l')' 

Terms/formulas in declassification pairs may not contain programs, updates 
or logical variables. Non-interference for a level I in the presence of a declassifi¬ 
cation environment is then defined straightforwardly by only considering states 
that are equivalent w.r.t. the declassification pairs that declassify to I (or lower). 

Definitions (Non-interference with declassifications). Let V = (L,G 
,DE). Given a program p, any two states si,S 2 , any first-order structures M 
and any variable assignments fi, such that valM,si,i3(v) = {si} ond valM,s 2 ,i 3 (v) = 
{S 2 }. Then p is said to be non-interfering with respect to V iff for all levels I G L 
with DP — U/'c/ DE(1'), when si S 2 and si S 2 then s[ S 2 . 

To specify non-interference with declassifications as a dependency problem, 
we revisit our definition of term dependencies to be parametrised on a set of 
declassification pairs DP. Definition IH] varies from Definition [S] only in the addi¬ 
tional requirement that Si and S 2 are HP-equivalent. 

Definition 9 (Term dependencies with declassifications). Given a pro¬ 
gram p, a term t and a set of declassification pairs DP. The term dependencies 
with declassifications oft under p is defined as the smallest set D(t, p, HP) C W 
of program variables such that the following holds for all states si, S 2 , for any 
first-order structures M and any variable assignments (3 with valM,si,/ 3 (p) = {s)} 
and valM,s2,i3(p) = {^l- If ~dp S 2 and for all y G T>(t,p,DP) si(y) = 82 ( 7 ), 
then valM,s[,i3(t) = val m ,s'.^,p(t)■ 
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We can now define non-interference in the presence of a declassification en¬ 
vironment, by determining the dependencies of a variable x in the presence of 
all declassifications to a level below lvl{x). 

Definition 10 (Dependency-Based Non-Interference with declassifica¬ 
tions). Given a policy V = DE). A program p is non-interfering with 

respect to V iff for each variable x G W, with DP = Ui'Ci-ui(x) DE{1'), for all 
variables y G D{x,p, DP), it holds that lvl{y) C lvl{x). 

Lemma 2. Definitions^^ and \l(J\ are equivalent. Proof in App.\Bf^ 

3.3 Non-interference with declassifications as a formula 

Approximating the dependencies of a program variable x as a set of other vari¬ 
ables results in a significant loss of precision, as it eliminates all knowledge about 
how the dependencies contributed to the value of x. This makes it impossible to 
determine whether some dependencies can be removed due to declassification. 
Intuitively, we need to know what information about the initial state is recorded 
in the value of x in the final state. The approach taken here, is to record how the 
final value of x can be computed from the initial state. Then, we can inspect this 
computation and determine whether it contains any declassified information. 

Naively, we could introduce the dependency variable x"*®? as done in [BHW09] . 
except now tracking a term that represents this specialised computation in¬ 
stead of the explicit set of dependencies. That is, given a program p with 
yo,lM,s,i3ip) = {s^}, we would have that val m, s,i3is' = voIm.s' Mul¬ 
tiple terms can represent the same information, hence, simply encoding this 
specialised computation as a single term t is problematic. 

For example, the term x - x represents the same computation as 0, but the 
variables occurring in each term (i.e. the dependencies) are different. At the same 
time, x+y specifies the same information as the term y+x, but the syntactic term 
is different. Therefore representing the computation as one specific term might 
restrict us to specify the declassification terms in the same syntactic form. 

These issues can be addressed by representing the computation not with a 
specific term, but with an equivalence class of terms. Two terms are said to be 
equivalent if they both evaluate to the same value in any context. 

Definition 11 (Equivalent terms). Two terms t, t' are equivalent, written 
t K. t', iff. for all first-order structures M, states s and variable assignments j3, 
valM,s,pit) = valM,s,p{t')- 

As is common, we denote with [f]~ the equivalence class of term t, i.e. the set 
of all terms equivalent to t. Analogously, we also introduce equivalence classes 
of formulas, but focus in the remainder of this section on terms only. 

We extend our syntax with a sort for equivalence classes EC G T. As terms of 
this sort we introduce a Herbrand symbol for every concrete function, predicate 
and program variable symbol in the signature. We denote these symbols using 
[•] and preserve the arity but substitute all sorts for the universal sort EC. For 
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example, [x] : EC, [17] : EC, [+] : EC —EC —>■ EC and [>] : EC —)• EC —EC. We 
naturally extend this syntax for function application, e.g. we write [+]([x], [17]) 
as [x + 17]. The Herbrand terms are then evaluated to the equivalence class 
that they represents, i.e. valM,s,i 3 {[i\) = [ijra- This implies that, for example, 
valM,s,p{[^ - x]) = valM,s,i3{W)- 

We update the evaluation function for programs to ensure that x"^®? maintains 
the equivalence class of computations representing the information that variable 
X has on the initial state. We give special treatment to the control statements 
since we need to capture the implicit dependencies. For a conditional statement 
branching on (/?, we evaluate each branch which gives us, per variable x, the 
equivalence classes ei and 62 for each computation. We select from each class a 
representative term ti and ^2 (for our purpose it does not matter which exact 
term is selected) and update x"^®? to [if {'^)then{ti)else{t 2 )\. For while loops we 
introduce dedicated symbols to summarise the computation, over-approximating 
dependencies as all variables contributing to the loop and its condition. 

The updated semantics (given in App. IA.2I) allows us to approximate the 
dependencies of a program variable x by picking any term t € x"^®? and taking 
pvars(t), the set of program variables occurring in t. 

Lemma 3 (Correctness of x*^®?). For all programs p and program variables 
X, for any state s, first-order structure M, and variable assignment (3 with 
valM,s,p{p) = {s^} and = [y]~ for all y G W, it holds that I?(x,p) C 

pvarsft) for each t G s'(x‘^®P). (Proof: see Avvendix \B.ft\) 

In the absence of declassifications, we can thus phrase the security condition for 
program variable x with lvl{y) % lvl(x.) in program p as follows: 

x'^^P = [x] & y^^P = [y] -> [p]prars(C(x'^^P)) C {x} 

Here C selects an arbitrary term from the equivalence class, i.e.. C([t]Rj) G 
which, by Lemma[31 gives a correct over-approximation of the term dependencies. 
Our calculus implements a natural implementation of C, namely to take exactly 
the term that currently syntactically represents the equivalence class. 

A declassification environment conditionally allows us to ignore some of the 
program variables in the term dependency. To reflect this, we replace the function 
pvars ■ C with the undefined function deps. Let {<p-,t) G DE{1) with L denoting 
the set of program variables of level I or lower. We then define the dependency 
sets of the equivalence classes by adding the assumption: 

VEC e. deps(e) = if{ip & e = [t])then(L)else{h(e)) 

which states that when the declassification condition (p holds in the initial state 
and the equivalence class e contains the term t (which specifies the declassified 
information) then e’s dependency set is simply the set L. Otherwise, the de¬ 
pendencies are over-approximated by the function h, which applies deps on the 
sub-computations forming e. We define h inductively over the term structure 
used to represent equivalence classes: 

/i([x]) = {x} h([f(ti,... ,tn)]) = deps{ti) U • • • U deps{t^) h([! ip]) = deps{ip) 
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and h applies deps similar homomorphic on all other terms and formulas. 

Multiple declassifications can be defined by nesting single declassifications. 
For instance, for the decryption program p from Fig.[I] we can consider the pol¬ 
icy DE{Lov) with two declassification pairs {(true, i^), ((^, cipher*key)}. Here, 
ip = tpi Sz (p 2 with Pi = (cipher * key)%256 = 0 and p 2 = !(((cipher * 
key)/256)%256 = —1), specify together when the decrypted message can be re¬ 
leased. Namely, it is always released whether the validity check of the decrypted 
message was successful or not, but the message itself is only released if it has a 
valid structure. The adherence of p to this policy can be encoded as a formula 
in our logic as follows: 

cipher‘^®P = [cipher] & key‘^®P = [key] & VEC e. deps{e) = 
if (true & e = [p]) then {{res}) els e{ (1) 

if{p & e = [cipher * key])t/ien({res})else(/i(e))) —>■ [p]c?eps(res‘^®P) C {res} 

The following lemma ensures soundness of the above non-interference encoding: 

Lemma 4 (Soundness). Given a policy V = {L,G^DE). Let INIT he the 
conjunction of formulas y‘^®P = [y] for every y € W, DEPS the formula defining 
deps as described above, and LVL(x) the set of program variables with a level 
I' C Ivl (x). Then for every program p, the validity of 

INIT & DEPS -> [p]deps(x'^®P)) C LVL{x) 

for each x € W implies non-interference of p as per DeRnition \l(A (Proof: By 
Lemma\^and correctness of the DEPS encoding, see Appendix\B.j}j 


4 A calculus for dependencies 


We present here the sequent calculus for our program logic as defined in Sect. [S] 
The calculus follows the symbolic execution paradigm, but with some changes 
compared to the calculus defined in Sect. 12.11 We start with the calculus rule for 
dealing with assignments: 


assignment'^®*’ 


r => {u} {x := t II x'*®*’ := wrap{t)}[. . .]p, A 
r => {u} [x = t; . . .]p, A 


As we can see the rule is almost unchanged to the version given in Sect. 12.11 
except that in addition to updating the value of x also the value of the ghost 
variable x‘^®p is updated to capture the dependencies of x faithfully. The value 
of x‘^®P is updated to the Herbrand term computed from t by function wrap. 
Note, wrap is not a function of the logic, and hence, not part of the syntax - 
instead it is a meta function which given a term returns a term. For instance, let 
t above be instantiated with the term x -|- y (x and y being program variables) 
then wrap{x -I- y) = [-I-](x‘^®p, y^®P). The full definition of wrap can be found in 
Figure [9] in Appendix IA.21 
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The conditional rule is changed more fundamentally for two reasons (i) we 
need to track implicit dependencies introduced by the condition and (ii) to cap¬ 
ture the dependencies as precise as possible: 

T {u} {xP’’^ := x}[pl]{x* x}{r}[p2]{r := x}{r}{«}[. . .]^.A 

r {m} [if (yi){pl>else{p2>; Z\ 


where 


~ X = ... ,x„,x^®*') are all variables changed in pi or p2 with their 

corresponding dependency variables, 

— ifP’'® = y-P'i'i^dep ypre 

A V-^1 ? -^1 ? • • • 1 -^n 5 

are lists of fresh variables, 

— r is the resetting update x := x^”'®, and 

— u is the collection of parallel updates for all Xi,x^®*' G x: 


^pre ^ ^predep ^ ^ ^pre ^ xP’'®®*®^), X* = (xj, . . . , X^) and X® = (j 


1 ) ■ 


Xi := if {ip)then(x\)else(xl 


— 


= [if {wrap (<p)) then ) else (x®’“^)] 




In contrast to the standard rule, the above rule does not split the proof into two 
branches. Instead it computes first the effect of the then-branch pi and stores 
the values of the modified variables by assigning them to the fresh variables x*. 
Afterwards the values of the modified variables are set back to their values before 
execution of pi. Next the else-branch p2 is executed, the values of the modified 
variables is saved in x® and again reset. Finally, the values stored in x* and x® 
are combined (in update v) using conditional terms such that they describe the 
final values of the variables x and 


Example 4- Assume the sequent => [if (b) {x=l} else {x=2>; .. .](p. Apply¬ 
ing rule ifElse‘^®P we get the sequent (x, b are program variables) 

{xP'^® := x||xP'^®‘*®P := x‘*®P} [x=1]{xP x||x“‘=p := x‘“=p} {x := xP’^‘= ||x‘'®p := xP’^^^^p} 

[x=2]{x" := xllx'^'P := x‘'®P} {x := xP'^Hx^'P := xP"®‘'®P} 

{x := i/(b)t/ien(xP)e/se(x")||x‘“=P := [j/()t/ien()e/se()](b‘'®P, x^^'p,x'^'P)} [.. .[y 

After applying assignment‘^®P twice and simplification the above sequent becomes 
=> {x := i/(b)t/ien(l)e/se(2)||x‘‘®P := [i/()t/ien()e/se()](b‘*®P, [1], [2])} [.. .]y> 


The following rule demonstrates how to reason about dependencies of equiv¬ 
alence classes whose representative is a conditional term: 


ifElseSplit^^P 


deps{[(p]) U deps{if{(p)then{lti])else{[t 2 ])) <^L,A 
r => deps{[if {ip)theTi{ti)else{t 2 )]) C L, A 


The above rule is sound as the conditional term in the premise causes the proof 
to split into two branches in which the dependencies of the then-branch resp. 
else-branch are included. 

In addition to the above rules we need some rewrite rules for equivalence 
classes, for instance, [x -I- 0] [x] or [if {(p)then{t)else{i)\ [t] which allows us 

to prove that two equivalence classes are equal. 
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As it turns out the presented approach does not require a special loop invari¬ 
ant rule, but can use the classic loop invariant rule shown below 


r 

loopinvariant — 


{u\Inv,A /nt;, (p => [p]/nri Inv,\ip 
r => {M}[while((p)-[p}; . . A 




The loop invariant rule splits the proof into three branches: (i) in the first branch 
one has to show that the invariant Inv holds just before entering the loop; (ii) 
the second branch requires to prove that the loop body preserves the invariant, 
i.e., assuming the loop condition ip and invariant hold before execution of the 
loop body then both hold again after the execution; and finally in (iii) we have 
to prove the original post condition (j) when exiting the loop using only the 
assumptions that the invariant holds and the loop guard was evaluated to false. 
The only thing which changes in our logic is that the loop invariant formula Inv 
must also state invariants about the dependency variables 


5 Example 

5.1 Decryption 

Let INIT & DEPS —> [p]deps(res‘^®P) C {res} be the summarised formula 
of equation (ED from Sect. [3] specifying the non-interference for the decryption 
program from Fig. [TJ Abbreviating the antecedent with P and the formula after 
the program with ip, we get as initial sequent: 

P [nisg = cipher * key; paddingOk = msg ’/, 256 == 0; ■ ■ ■]lp 

Applying assignment‘^®P twice and some update rewrite rules, we get: 

P {u} [if (paddingOk) { . . lelsef . . . }]'0 

Where, u contains the updates msg‘^®P := [cipher * key] and paddingOh”^®? := 
[(cipher *key)%256]. After two applications of ifElse'^^P and three assignment‘^®P; 
we get after update simplification and applying the update on ip: 

P => deps{[if{(pi)then{if{(f 2 )then{c±pheT*'k.ey)else{—l))else{—l)]) C {res} 

where (fi = (cipher * key)%256 and ip 2 = ((cipher * key)/256)%256. The 
rewrite rules for equivalence classes allow us to replace the syntactic term with: 

P deps{[if{(fi & ip 2 )then{c±pheT*'k.ey)else{if (ipi)then(—l)else{—l))]) C {res} 

Which in turn can be rewritten to (also replacing ipi & ip 2 with the equal ip): 

P deps{[if {ip)then{c±pheT * 'key)else(—l)]) C {res} 

We can then apply the rule ifElseSplit"^®^: 

P deps{[ip\) U deps(i/((/?)f/ien([cipher * key])else([—1])) C {res} 
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First, we observe that F allows us to derive that deps{[(p]) = {res}. Then, we 
can split on the formula tp: 

r, ip =P {res} U deps([cipher =i= key]) C {res} 
r ,! ip {res} U deps([—1]) C {res} 

For the first sequent, we can now derive that deps([cipher*key]) = {res}, while 
in case of the second sequent, we get deps([—1]) = h([—1]) = 0 

r, ip => {res} C {res} and F,! ip {res} C {res} 

Both are trivially valid and thus proving that the program from Fig. [T] satisfies 
non-interference under the specified declassification policy. 

5.2 Loop invariants 

As is usual in program verification, loops can 
be dealt with using invariants. Typically, this 
requires the interaction with a human user to 
specify an appropriate invariant. Consider the 
program in Fig. 15.21 which uses a while loop 
to multiply the (positive) numbers m and n, 
storing the result in r. The variable mO is an 
auxiliary variable to record the pre-state of 
variable m, allowing a human user to specify the invariant = [(mO — m) * n]. 

A strong advantage of the approach presented here is that invariants can 
be generated automatically using the algorithm presented in [BHW09] . For the 
above program the generated loop invariant would be c?eps(r'^®P) C {m, r,n}. 
Although these invariants drop the computational history of r, they appear 
sufficient for the verification of our security conditions. 

5.3 Heap 

As a final remark, we discuss how an explicitly represented heap can be inte¬ 
grated in our calculus. By treating the heap like any other program variable 
with dedicated functions store and select, our extended calculus can be ap¬ 
plied as-is to programs with heaps. Let p be the program from Fig. |2l The 
sequent (without declassifications) 

F [p]deps([select(heap‘^®P, objA'^^P, f)]) C {} 

would be valid, were it not for the possibility of objA being an alias of objC. 
Applying the rules for assignments, conditionals and simplifications, we obtain: 

F => • • • {objC‘^®P := [if{h = 0)t/ien(objA‘^®P)else(objB‘^®P)]} 

deps([select(store(heap‘^®P, objC^^P, f, 17), objA'^^P, f)]) C {} 

Thanks to representing the heap explicitly, the fact that the value of objC de¬ 
pends on h is also present when reading an element from the heap. The equiv¬ 
alence class describing the dependencies of obj A. f thus correctly contains the 
dependency on h and the sequent cannot be proven valid. 


mO = m; 
r = 0; 

while (m > 0) { 

r = r + n; 
m = m - 1; 

} 

Fig. 3. Multiplication. 
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6 Related work 


The seminal work [SM04) proposes a type-based approach to delimited infor¬ 
mation release that requires to mark program points at which declassification 
occurs explicitly. Further type-based systems have been developed by |BPR07j 
and [BN05) . but these omit certain features like support for declassification. 

The most popular type-based system that allows for declassification is the 
Jif |Mye99| approach and tool. Its rich set of features allows it to be used for real¬ 
istic programs [CCMOSIHKMHOb] . The programming language Paragon |BvDS13] 
presents an alternative type system that allows for the enforcement of dynamic 
policies. That is, rather than explicitly declassifying information, the ordering 
between security labels can be changed during program execution. 

There is also a number of logic-based approaches to information-flow se¬ 
curity that make use self-composition |DHS03IDHS05IBCK11) . In contrast our 
approach is based on the explicit tracking of dependencies and not on the com¬ 
parison of two program runs. This avoids the need for optimizations to prevent 
the actual repeated execution of two runs like in product programs |BCKll) . In 
addition to self-composition, |DHS03IDHS05] also present an alternative seman¬ 
tic encoding of non-interference, but which lacks abstraction requiring a higher 
degree of interaction during the proving process. 

[BNR08) introduce flowspecs: small declassification specifications on a small 
group of statements that should be checked using a program verification, inter¬ 
leaved with the type-checking of non-interference. Since specifications can only 
be defined on the program’s pre-state, this modular approach requires that no 
assignment is made to variables which are to be declassified at a later point. 

In [HPRW08] the authors also integrate a type-based system for information 
flow into a program logic. Their logic guarantees to find a proof automatically 
for all programs that are deemed secure by the type-based system. However, 
their logic has to be designed freshly for any other kind of type-based systems. 

The approach presented in |BHW09] is based on abstract interpretation and 
explicit dependency tracking. We extended the precision of their approach by 
tracking not just the sets of variables, but also the computational structure of 
the dependencies. This allows us to reason about delimited information release 
properties and not only non-interference properties. 


7 Conclusions and future work 

In this paper we presented a program logic and calculus suitable to express 
and prove that a program has secure information-flow with respect to non¬ 
interference and conditional delimited information release. The program logic 
was based on explicit dependency tracking instead of self-composition. As future 
work we plan to integrate our approach in the abstraction framework introduced 
in [BHW09] and to perform experiments to evaluate the degree of automation. 
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A Semantics 


A.l Basic Semantics 

The semantics of terms is defined in Figure SI for formulas in Figure SI for 
programs in Figure S] and for updates in Figure [T] 

In Figure SI we denote with fjy the variable assignment f3 that maps logical 
variable y to the value v instead of the original value. In FigureSl we use a fixed- 
point semantics for while loops. In Figured to account for the ‘right-most-wins’ 
semantics, we define the semantics for elementary update and parallel updates 
simultaneously. 


valM,s,p{^) = s(x) 
valM,s,p(y) = Piy) 

Vdl M,3,p (^f • ■ • jtii) — . . . , Vdl M,3,p 

vdl 3 j^ if ,s,/3(v^) — 


valM,3,0{ifi'fi)then{ti)else{t2)) = , , 

valM,s ,0 (^ 2 ) otherwise 

valM,3,pi{u} t) = vdlM, 3 ',p{t) where s' = valM,3,p{u) 


Fig. 4. Definition of the evaluation function valM,a,p for terms. 


wlM.s./3(true) 
t'alM.s,/? (false) 
r^a/jvf,s,/3 (p(ti, • ■ •! tn)) 
valu.s.pi'- <p) 

VdlM,3,p{‘Pl & ¥’ 2 ) 

valM,3,p{‘Pi I ¥’ 2 ) 

VdlM,3,p{V’l —> <^ 2 ) 
vdlM,3,p{^y-‘p) 
vdlM,s,p{'^y-‘p) 

vdlM,3,piif{<fii)then{ip2)else{ip3)) 
vdlM,3,pi{u} 95 ) 
VdlM, 3 ,pi'\Jp]‘P) 


= tt 

= ff 

= tt iff {valM,s,p{ti), VdlM,s,p{t„)) G l(p) 
= tt iff valM,3,p{y^) =ff 
= tt iS ff ^ {vdlM,s,p{‘Pl), VdlM,3,p{v>2)} 

= tt iff tt G {vdlM, 3 ,p{y:>i),vdlM,s,p{y:> 2 )} 

= VdlM,3,p{'- ‘fil I <fi2) 

= tt iff tt G {riafjvf.s.aj (ip) | w G D} 

= tt iS ff ^ {vdlM,s,p^{‘fi) I n G D} 

_ J VdlM,3,p{>fi2) if VdlM,3,pi‘Pl) = tt 

\vdlM,3,p{‘P3) otherwise 
= vdlM, 3 ',p{y>) where s' = vdlM,s,p{u) 

_ j VdlM,3',p{<fi) if VdlM,3,p{v) = {s'} 

1 tt otherwise 


Fig. 5. Definition of the evaluation function valM,s,p for formulas. 
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1 ^ r '1 u >( \ \va.lM,s,p{t) ify = x 

w(m,s,/ 3 (x = {s } where s (y) = < . 

Is(y) otherwise 


wZm,s,/3(pi;P2) = < 


ria/M,s./3(if(¥5){Pi}else{p2}) = < 
i^a^M,s,/9(while(9s){p}) = < 


valM,s',p{p2) 

if m/M,a,/3(pi 

) = {s'} 

0 

otherwise 


valM,s,i3{pi) 

if valM,B,p{p) 

= tt 

valM,s,p{p2) 

otherwise 


{s'} if 3n > 0 

1 : s = So, s' = 

Sn and yi < n : 

ValM,3i,/3 

(p) = {si-l-i} and valM,3i,p{‘p) 


and valM,sn,i3i‘fi) = ff 
0 otherwise 


Fig. 6. Definition of the evaluation function valM,s,p for programs. 

w1m.s./3(xi := ti II • • • II x„ := = {x i-)- s(x) | x ^ {xi, . . . ,x„}} U 

{x !->■ valM,s,p{tk) I x = xfe and x 0 {x^+i,..., x„}} 


Fig. 7. Definition of the evaluation function valM,s,i 3 for updates. 


A.2 Computation-Tracking Semantics 

Figure [8] defines the updated evaluation of programs; where we focus on the 
changes to the dependency variables. 

For assignments we wrap the term using the syntactic function wrap shown 
in Figure |9l This function homormophically replaces all symbols by their Her- 
brand counterparts and all program variables by their corresponding dependency 
variable. 

For conditional statements we evaluate both branches, select a term from 
the equivalence class resulting from each branch and combine them in a single 
conditional term. Here, C is the choice operator that selects any term from an 
equivalence class, i.e. C(e) G e for all e : EC. 

For while loops we introduce an infinite set of function symbols W, such that 
W(y, z) returns the value of variable y at the end of the while loop, given the 
initial values z of all variables occuring in the condition tp or body p of the while 
loop. The W functions are introduced only to have a well-defined semantics that 
tracks the dependencies. The function symbols are not used in the calculus. 
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valM,s,i3ilt]) 

valM,s,p{y^ =t) 
wZM,s,/3(if (‘p){Pi}else{p2}) 


valM,s,/3{vh.ile{(p){p}) 


{ valM,s,p{t) if y = X 

valM,s,p{wrap{t)) if y = 

s(y) otherwise 

S[ if valM,s,p{^) = tt 
S 2 otherwise 
where Si = valM,s,p{vi), S'i = 0 iff Si = 0, 
otherwise Si = {si} and S' = {s'} with 
' [if(ip')then{ti)else{t 2 )]a 


■s'i(y) = S 


= < 


if y = x^^P, 

<fi' = wrap((fi), 
ti = C(si(x-*‘=P)) 

{si(y) otherwise 

{s"} if 3n > 0 ; s = so, s' = s„ and Vi < n : 

valM,Si,p{p) = {si+i} and valM,Si,p{v>) = tt 
and valM,sn,p{'P) = jJ with 


."(x) = { { 

{ s (x) ot 


X = y"^P 

otherwise 


0 otherwise 


Fig. 8. Updated definition of the evaluation function valM,s,i 3 for dependency 
tracking. 


wrap{x) = x'**'*’ 

wrap(f(ti, ...,tn) = [f]{wrap{ti),... wrap{tn)) 
wrap{if {(p)then{ti)else{t 2 )) = [if {)then{)else{)]{wrap{ip), wrap{ti), wrap{t 2 )) 
wrap (true) = [true] 
wrap (false) = [false] 

wrap(p{ti, ...,tn) = [p](wrap(ti),... wrap{t„)) 
wrap (lip) = [!](wrap(ip)) 
wrap{(f>i o Lp 2 ) = [o](wrap((pi), wrap(ip2)) 

Fig. 9. Definition of the syntactic operator wrap. 
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B Proofs 


B.l Equivalence between non-interference and dependency-based 
non-interference 

Non-interference implies dependency-based non-interference: 

By contraposition. Assume that there exists a program variable x which 
has a variable y G X>(x,p) with lvl{y) % lvl{x). Therefore, program p does not 
satisfy dependency-based non-interference (Definition IHl). Since y € I?(x,p), by 
Definition [5] there must be two states si, S 2 such that si S 2 , si(y) ^ ■S 2 (y), 

valM,si,p{v) = {si}, and s^(x) ^ S 2 (x). Consequently, program p also does not 
satisfy non-interference (Definition |3|). 

Dependency-based non-interference implies non-interference: 

Given a program p and security level Z. If a program p is dependency-based 
non-interferent then, by Definition [5] for each variable x with level C Z, for all 
y S I?(x,p) we have Zr)Z(y) Cl Z?;Z(x). Given two states si, S 2 such that si w; S 2 , 
it thus follows that si(y) = S 2 (y) for all y € V(x,p). If va/M.si,/ 3 (p) = {s^} then 
by Definition [S] (x) = S 2 (^) each variable x with level Z' C Z, and hence 

S 2 - Therefore, program p is non-interfering (Definition |4]). 

B.2 Equivalence with declassifications 

Non-interference implies dependency-based non-interference: 

By contraposition. Assume that there exists a program variable x which has a 
variable y G T>(x,p, DP) with IvI{y) % lvl{x). Therefore, program p does not sat¬ 
isfy dependency-based non-interference (Definition fTOl). Since y G 'D{x,p, DP), 
by Definition [9] there must be two states si, S 2 such that si S 2 , si ~dp S 2 , 

■si(y) ■S2(y), vuIm, si,p{v) = {s'}, and s'i(x) 7 ^ S 2 (x). Consequently, program p 
also does not satisfy non-interference (Definition [ 8 |) . 

Dependency-based non-interference implies non-interference: 

Given a program p and security level Z. If a program p is dependency-based 
non-interferent then, by Definition [10] for each variable x with level Z' C Z, for 
all y G D(x,p, DP) we have ZvZ(y) C lvl{x). Given two states si, S2 such that 
Si S 2 and si ~_dp S 2 , it thus follows that si(y) = S 2 (y) for all y G D(x, p, DP). 
If valM,si,p{p) = {s'} then by Definition |S] s}(x) = S 2 (x) for each variable x 
with level I' Q I, and hence Therefore, program p is non-interfering 

(Definition | 8 |) . 

B.3 Correctness of x'^®p 
Auxiliary lemmas: 

Lemma 5. For all programs p and program variables x, for all state si,S 2 , 
first-order structure M, and variable assignment f with valM,si,p{p) = {s}} 
and voIm 82 p{v) = {S2}) we have si(y‘^®P) = S2(y‘^®P) for all y G W implies 
s'i(x"^P) = s^x'^P). 
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Proof. By inspection of valM,s,i 3 we observe that the state s is irrelevant for 
determining the value of except for the evaluation of conditional statement 
and program variables. In these cases, the value of other dependency variables 
is used to construct a new value. Since we have that these values are the same 
in any two states (for the conditional statement by induction) also the newly 
constructed value is equal in any two states. 

Lemma 6. For all programs p and program variables x, for any state s, first- 
order structure M, and variable assignment ft with valM,s,/ 3 {'p) = {s^} and 
= [y]® for all y € W, it holds that valM,s, 0 {t) = s'(x) for each t € 

s'(x‘^®P). 

Proof By induction on the structure of p. 

— Case X = t: 

Here s'(x) = valM,s,/ 3 {t) and s'(x‘*®p) = wrapft) with each program variables 
y substituted with [yja;. By definition of all terms in this equivalence class 
evaluate to the same value in state s, so to valM,s,/ 3 {t). 

— Case pi; P 2 : 

We have voIm.s, pivi) = {s^} and valM,s',/ 3 {p 2 ) = {s”}- Let r' be like s' but 
with r’'(y‘^®P) = [y]~ for all y G VV, such that valM,r’,p{V 2 ) = W}- 
By induction, valM,r', 0 {tx) = r"(x) for all fx € r"(x‘^®P). We also have that 
since r' differs from s' only in the dependency variables, r"{x) = s"{x). 
Therefore, val m y, 0 {tx) = s”(x) for all t^ G r"(x‘^®P). 

We also have by induction that valM,s, 0 {ty) = s'(y) for all ty G s'(y‘^®P). We 
can therefore substitute each variable y in tx with any term ty G s^(y'^®P) and 
evaluate t^ in state s instead. That is, wa/M,s,, 3 (ix[y ^y]) = s"(x) for all 
tx G r"(x‘^®P) and all ty G s'(y‘^®P). 

We finally observe that the s"(x‘^®p) equivalence class is exactly the set fx[y 
ty] for all tx G r"(x‘^®P) and all ty G s'(y‘^®P). Therefore, valM,s, 0 it) = s"{x) 
for each t G s"(x‘^®p). 

— Case if((/9){pj^}else{p2}: 

Let valM,s,pfpi) = {sil and voIm.s, 0 iP 2 ) = {s^}- We have that s'(x) = s^(x) 
if valM,s, 0 {p) = tt and s'{x) = s' 2 {x) otherwise. 

For all terms t G s'(x‘^®p) we have t « if{(p)then{ti)else{t 2 ), with (by induc¬ 
tion) valM,s,0iti) = s'i(x) and valM,s, 0 {t 2 ) = S2(^)- If 'oalM,s, 0 {p) = tt we 
have that valM,s, 0 {if {p)then(ti)elself 2 )) = valM,s, 0 {ti) = Si(x) = s'(x), 
otherwise we have that valM, 8 , 0 {if{p)then(ti)else(t 2 )) = valM,s, 0 (t 2 ) = 
= s'(x). 

— Case while(i^){p}: 

Directly by definition of the W function symbols, for all terms in t G s'(x‘^®p) 
we have valM, 8 , 0 {t) = s'(x). 

Lemma 7. For all well-typed terms t; X>(t,;) C pvarslf). 

Proof. Our valuation function valM, 8,0 determines the value of terms only by the 
program variables that actually occur in that term. Therefore, all dependencies 
of a term are present in the syntactic representation of that term. 
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We can now show that for all programs p and program variables x, for any state 
s, first-order structure M, and variable assignment /3 with valM,s,i3ip) = {s^} 
and s(y‘^®P) = [yja; for all y G VV, it holds that I?(x,p) C pvars(t) for each 
t G s'(x'^®P). 

Proof. By Lemma 0 this is implied by showing that X>(x,p) C X>(f,;). By defi¬ 
nition of T>; for any two states si, S 2 we have if si(y) = S 2 (y) for all y G 'D{t ,;), 
then valM,si.p{t) = valM,s 2 ,p{i)- 

Let valM,si,p{v) = {Si}- By Lemma [S] we have that s'(x‘^®p) = s'^(x‘^®p) = 
S 2 (x‘^®P), therefore t G s'(x‘^®p). By Lemma [5] we conclude that valM,si,p{.t) = 
s'(x), and since we had valM,si,0it) = we can conclude that Si(x) = 

S 2 (x). Therefore Vit ,;) is a correct over-approximation of the dependencies of x 
under p, that is I?(x,p) C V{t, ;) (by definition of V) which is what we had to 
show. 

B.4 Soundness 

Given; 

INIT & DEPS -> [p]deps(x'^®P)) C LVX(x) 

If the declassification environment is empty, then DEPS is VECe. deps{e) = h{e). 
Then c?eps(x'^®P) = pr;ars(C'(x‘^®P))) where C selects the syntactic term that 
happens to represent x‘^®p, which by Lemma[3]gives us that II(x, p, DE) C LVL{x) 
which implies non-interference with declassification. 

If the declassification environment is not empty, for each declassification pair 
(if, t) then some program variables occurring in t may be removed from the 
set returned by dtps. However, this only happens if ip holds, therefore these 
would also be excluded by definition of D and still imply non-interference with 
declassification. 
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